Gateway unit for connecting sub-networks, in particular in vehicles

ABSTRACT

A gateway unit for connecting subsystems, in vehicles in particular, in which at least one modular logical software gateway is used which routes messages between precisely two subnets, thus providing only one individual connection pathway.

FIELD OF THE INVENTION

The present invention relates to a gateway unit for connecting subnets,in vehicles in particular.

BACKGROUND INFORMATION

To make new services in the vehicle possible, communication among thecontrol units located in different bus segments is indispensable. Suchcommunication may take place only if the different bus segments areconnected to one another via one or more gateway units. A gateway unitconnecting two bus segments has the function of relaying messagesreceived on one bus segment to another bus segment (routing). Thecomplexity of such a gateway unit increases with the number of bussegments to be connected. When designing the network connectionarchitecture of a vehicle, an attempt is made to find an optimum for thecharacteristics of tolerable delay for message routing, error tolerance,flexibility, expansibility, and cost. Depending on the application,central gateway units having a star architecture or a plurality ofgateway units which may be connected by a backbone bus, for example, areused. The gateway units via which different buses are connected areconfigured (for example, via tables). As a result, pure message routingto another segment does not require a change in the software. However,if the type and number of connected bus segments change, major changesare needed, in which not only the existing configuration tables must beadapted, but the entire software must be rewritten to meet the newrequirements. The complexity of the central configuration and therouting software thus increases significantly with the number ofconnected bus segments.

SUMMARY

A modular design of a gateway unit is provided, in which a gatewayincorporated in the software (logical software gateway) is responsiblefor routing messages between exactly two subnets makes it possible toexpand gateways without need for changing the existing gateway softwareand/or the existing configuration tables. Adding or omitting such amodular gateway when changing the network topology avoids such changes.Similarly, it is also possible to remove a bus segment in the case of acentral gateway unit without affecting existing connection pathways.

Furthermore, the above-mentioned modular gateways allow errorlimitation, because if a gateway is not operational, the other gatewayscontinue to perform their functions independently of the defectivegateway. An error is thus limited to the directly affected gateway; theconnection to other bus segments remains unaffected. If an error occurson a bus segment, messages continue to be routed without limitation viathe other bus segments.

Furthermore, the above-outlined design is extensible in a flexiblemanner and adapted to the network connection architecture. If anadditional subnet is added to a central gateway, only the additionalmodular gateways must be added. The existing modular gateways are notaffected. If a subnet is removed, the gateways connected to this subnetare removed; the other gateways remain unchanged.

Since a logical gateway always only contains the function required forconnecting the two different subnets, a message is routed in thequickest possible way. Unnecessary overhead for routing a message isthus avoided. Because a logical gateway is responsible for connectingtwo subnets, the information flow may be monitored separately if thedata transfer takes place between a subnet having safety-criticalfunctions and a subnet having functions which are not safety-critical.This provides the possibility of optimum monitoring for firewallfunctionality, which may monitor each connection pathway individually. Alogical gateway which routes messages over an air interface may thusimplement stricter security mechanisms against external threats than alogical software gateway which routes messages between two CAN subnetsin the vehicle and is not directly exposed to external threats.

Furthermore, the above-described architecture permits one or moregateways to be individually activated and/or inactivated, so that one ormore gateways may thus be switched on or off as a function of systemstates.

Furthermore, the complexity of the entire gateway unit is reduced,because the individual logical gateways are not connected to oneanother. It does not matter whether, for example, three logical gatewaysrun on one central gateway or on three separate point-to-point gateways.

Additional advantages result from an example embodiment of the logicalgateways, according to which routing tables are provided in each gatewayvia which the messages are routed and which are independent of thegateway software. This table-based approach permits the use of a toolfor configuring the gateway software. This approach also advantageouslyprovides a possibility to prioritize messages, so that certain messageswhich are to be routed preferentially are assigned a higher prioritythan other messages.

Furthermore, a scheduler is advantageously provided, which ensures,despite the division into several modular software gateways, that theorder of message routing is observed. In this way, a message arrivingfirst at the gateway also leaves the gateway first.

Further advantages may be derived from the following description ofexemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is explained below in detail with reference toexemplary embodiments illustrated in the figures.

FIG. 1 shows the basic principle of the above-described architecture ofa gateway unit connecting three bus segments.

FIG. 2 shows a preferred exemplary embodiment of such a gatewaytransmitting messages between a low-speed CAN, a high-speed CAN, and anSPI bus.

FIG. 3 shows a central gateway unit for connecting four subnets.

FIG. 4 shows point-to-point gateway units for connecting the foursubnets using the above-described gateway architecture.

FIG. 5 shows a gateway integrated in a control unit using a layer model.

DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1 shows a gateway unit 10, which is connected to three bus segments1, 2, 3 and has the function of routing messages from one bus segment toone or both of the other bus segments. The basic principle of thearchitecture shown are modular gateways (logical software gateways) 12,13, 23, such a gateway being responsible for routing messages betweenexactly two subnets. Gateway 12 thus routes messages from 1 to 2 andvice-versa; gateway 13 routes messages from 1 to 3 and vice-versa, andgateway 23 routes messages from 2 to 3 and vice-versa. Each logicalsoftware gateway thus describes an individual connection pathway betweentwo subnets, i.e., bus segments. Gateways 12, 13, 23 are designed assoftware programs, which are used to perform the protocol-specificadaptations needed for message routing between the two subnets.Depending on the exemplary embodiment, each subnet is an individualtransmission medium. For example, subnet 1 may be a low-speed CAN;subnet 2 may be a high-speed CAN, and subnet 3 may be an SPI bus. If anew subnet is added, for example, a MOST bus, additional logicalsoftware gateways are introduced. The existing ones do not need to bemodified. If a subnet, for example, the SPI bus, is removed, logicalsoftware gateways 13 and 23 are removed. Logical software gateways forall possible connections are to be written to have a universal gatewayfunction. Depending on the design of the gateway to be implemented,these logical software gateways are then combined to form one overallsystem. In general, not all subnets are directly connected to oneanother, so that only selected connection pathways are to be providedwith selected logical software gateways. If each subnet is to beconnected to each other subnet, N*(N−1)/2 logical software gateways areneeded. Variable N is the number of subnets in the overall system. Thus,for three subnets, there will be three logical software gateways; forfour subnets there will be six, and for five subnets there will be tenlogical software gateways. It is of secondary importance whether theselogical software gateways are located in one central gateway or in aplurality of point-to-point gateways.

FIG. 2 shows a detailed exemplary embodiment of features of the modulargateway architecture according to FIG. 1. Gateway 10, which ispreferably implemented as a program in a microcontroller of a controlunit, includes, in addition to the modular software gateways shown(:CANCAN, :CANSPI), bus-specific transmitting units, which monitoraccess to the bus medium. Receiving objects (:Rx-CAN, :Rx-SPI), whichdetermine into which logical software gateway an incoming message isrouted, are associated with each bus segment. Similarly, there arebus-specific transmitting objects (:TxCAN, :TxSPI) for the transmissionoperation, which monitor access to the particular bus and prevent morethan one modular software gateway from simultaneously occupying thetransmitting medium.

The software gateways (in FIG. 2: CANCAN:CANSPI) are internally composedof a plurality of software objects, which buffer incoming messages andperform the protocol-specific adaptations. One simple adaptation is, forexample, that a CAN message is to be sent from high-speed CAN having ID100 to low-speed CAN having ID 200. These protocol-specific adaptationsare then performed by appropriate programs (for example, in the simplestcase, by a table). Configuration tables are used for theprotocol-specific adaptations performed within the logical softwaregateways.

In a preferred embodiment, the bus-specific receiving objects areconfigured via routing tables via which the decision is made as towhether an incoming message is to be routed to no logical softwaregateway, one logical software gateway, or both logical softwaregateways. The subsequent treatment of the message is thus saved in therouting table for each incoming message type. Furthermore, it mayhappen, due to the different speeds of the buses, that only every 5^(th)message of a certain type (for example, engine speed) is relayed fromone bus segment to the other. This may also be implemented via theabove-mentioned routing tables in the receiving object. These routingtables are independent of the source code of the actual gateway, so thata change in the routing table results in little or no change in thesoftware of the respective modular gateway. The bus-specific receivingunit looks up the found message in the routing table and decides, on thebasis of the information contained therein, which logical softwaregateway contains the message for further processing.

The bus-specific transmitting units, i.e., the programs provided there,monitor access to the bus. If the bus has just been occupied, they makesure that no message is sent by any logical software gateway.

In addition, as mentioned before, the logical software gateways bufferthe messages to prevent loss of messages, for example, when the bussegment to which a message is to be sent has just been occupied. Amessage is thus kept in a wait loop before it is directly forwarded. Theinternal scheduler of the gateway unit takes notice of the messagehaving been placed into a wait loop. It causes the message to betransmitted by transmitting a message to the corresponding modularlogical software gateway, which then causes the message to betransmitted. Therefore, if a logical software gateway intends totransmit a message, it must report this intent to the scheduler. Itdepends on the order of the reports which software gateway first obtainsthe authorization for sending a message. This ensures that the correctorder of the messages is observed. If the system contains particularlyhigh-priority messages, the scheduler provides a plurality of methodsfor reporting an intent to transmit; these methods may be called by thelogical software gateways. The scheduler always processes thehigh-priority requests first and then those of normal priority, and itgrants transmission authorizations to the logical software gateways as afunction of the priorities. For example, each intent to transmit isprovided with a piece of information representing the priority of themessage, or the scheduler includes a table in which the priorities ofthe messages are marked; the scheduler reads the priority from thetable.

The above-described architecture and procedure permit the gate unit tobe configured via tables without modifying their software. For example,by modifying the parameter sets in the memory, the gateway may bereprogrammed for different message routing. If the same interfaces areused, the gateway software may be configured exclusively using parametersets. If other interfaces are connected to the gateway, a modularsoftware module is to be integrated into the gateway. Different gatewayconfigurations are thus generated by combining software modules, forexample, from libraries and by providing routing information.Integration of a new CAN interface having a new CAN matrix is basicallylimited to the inputting of the new routing information into the routingtable. CAN-CAN gateways of different baud rates may thus be integratedinto a system in a very short time. Testability and verification of theobtained codes are simplified by the fact that theconfiguration-dependent code is centrally tested and only an integrationtest for the new logical SW gateway, i.e., the new configuration, isperformed in addition to the system test.

FIG. 3 shows a gateway 10 for connecting four different bus segments: alow-speed CAN, a high-speed CAN, an SPI bus, and a MOST bus. Theabove-described architecture is also used here, logical softwaregateways (:CAN-MOST, :CAN-SPI, :CAN-CAN, :SPI-MOST), each implementingan individual connection pathway, being used. In addition, bus-specificreceiving modules (:Rx-Most, :Rx-CAN, :Rx-SPI) and transmitting modules(:Tx-Most, :Tx-CAN, :Tx-SPI) are illustrated as described above. Thedepicted architecture shows a central gateway unit connecting theabove-mentioned four bus segments. FIG. 4 shows another networktopology, which has six point-to-point gateway units 10 a, 10 b, 10 c,10 d, 10 e, and 10 f. Each of these point-to-point gateways contains theabove-described logical software gateway structure having transmittingand receiving elements for bus-specific connection. It is evident that,due to the above-described architecture, the physical network connectionarchitecture may contain all conceivable mixed forms between the twoextremes of a central gateway and a point-to-point gateway. The softwarearchitecture is independent of the physical network connectionarchitecture, so that it allows for connection in all conceivablearchitectures. The difference may be that, for the central gatewayvariant, the software runs on one microcontroller, while in thedecentralized variant it runs on different controllers.

Different options exist for configuring the gateway unit. The routingdecision is configured via routing tables. In this case, thebus-specific receiving objects determine into which logical softwaregateways a message is to be relayed. These receiving objects aretherefore configured using routing tables, which specify which messagesare to be relayed into which subnet and optionally under what conditions(for example, every 5^(th), etc.). The software of the software gatewaysthen implements the bus-specific adaptations and is independent of theactual routing procedure. The software gateways are then configured viaadaptation of protocol parameters. In this case, the logical gatewaysare configured via tables, which specify how the protocol parameters areto be implemented. The configuration may include here that a messagehaving ID code 100 must have ID number 200 when transmitted to the othernetwork segment. Furthermore, the routing tables via which thebus-specific receiving objects are configured are to be divided orcombined to adapt the gateway software to the different networkconnection architectures. This function is performed by an internalscheduler, which coordinates the logical software gateways in a centralgateway unit. The scheduler must be generated individually for thedifferent gateway variants.

In another embodiment, which is depicted in FIG. 5, the gateway is not astandalone gateway, but a gateway which is integrated into a controlunit having additional application functions. In this case the gatewaysoftware may also assume the functionality of a normal communicationdeck. This means that it should also be possible here to relay messagesto the actual applications and to receive messages from theseapplications for transmission. For this purpose, additional objectshaving the capability of removing or adding layer-specific protocolparameters are needed to relay the message to the next higher or nextlower level. These additional objects are normally part of the softwareof the normal communication network. FIG. 5 shows the layer model of acontrol unit 100, in which a CAN-CAN gateway is integrated. Adistinction is made between application system I and communicationsystem II. Three layers 1, 2, 3 are illustrated, a driver 102 beingprovided for the low-speed CAN and a driver 104 being provided for thehigh-speed CAN in a first layer. Furthermore, additional objects areintroduced into network layer 3 (CAN layer 3) which communicate withapplications A, B, and C via receiving and transmitting objects Rx3 andTx3. These additional objects buffer the messages if needed and add orremove protocol-specific parameters. The logical software gateway whichis integrated into this layer (CAN-CAN) routes messages from one bus toanother. Receiving and transmitting objects Rx2 and Tx2 are used asdescribed above for routing messages between the two CAN buses. Theyrepresent the interfaces between the layers. In another embodiment, anappropriate extension makes it possible to link two subnets on differentlayers. This is required, for example, when a transport protocol (forexample, ISO TP) is used. In this case, there is one logical softwaregateway per layer in which connection takes place. Thus, for example,one CAN-CAN gateway may be provided in layer 3, which transports CANmessages (e.g., speed information or fuel tank level information) inlayer 3, while another CAN-CAN gateway injects transport information,for example, a text for display in the vehicle computer, in a layer 4.Connection in higher layers may also be necessary to check the contentsof a message to be relayed. The contents may be analyzed only when thecomplete message has been received.

1-7. (canceled)
 8. A device for connecting subnets in a vehicle,comprising: a gateway unit configured to connect at least twosubsystems, wherein the gateway unit is made of at least one modularsoftware gateway, which routes messages between precisely two subnets.9. The device as recited in claim 8, wherein at least three subnets areconnected to the gateway unit, the gateway unit including a plurality ofmodular software gateways, each of the modular software gateways routingmessages between precisely two subsystems.
 10. The device as recited inclaim 8, further comprising: bus-specific receiving objects configuredto relay incoming messages to selected software gateways, thebus-specific receiving objects being provided for each subnet.
 11. Thedevice as recited in claim 10, wherein the receiving objects includerouting tables in which a treatment of incoming messages is configured.12. The device as recited in claim 8, further comprising: bus-specifictransmitting objects configured to monitor access to a particular bus,for each subnet.
 13. The device as recited in claim 8, wherein themodular software gateway is configured to buffer incoming messages andperform protocol-specific adaptations.
 14. A device for connectingsubnets in a vehicle comprising: a gateway unit configured to connect atleast two subsystems, the gateway unit being integrated in a controlunit having an application system and being provided in one layer of acommunication system of the vehicle, the gateway unit including at leastone modular logical gateway, the logical gateway connecting exactly twosubsystems.